Plansza do analizy bezbłędnej post mortem
Szablon "blameless" post-mortem pomaga zebrać informacje o incydentach, które miały miejsce w produkcji.
Ten „bezwinny” szablon Post-Mortem pomaga zebrać informacje o incydentach, które miały miejsce w produkcji. Przestrzeganie tego procesu oznacza, że inżynierowie, których działania przyczyniły się do wypadku, mogą dostarczyć szczegółowy opis:
jakie działania podjęli i o której godzinie,
jakie skutki zaobserwowali,
oczekiwania, które mieli,
założenia, które przyjęli,
ich zrozumienie osi czasu wydarzeń w miarę ich występowania.
i że mogą podać taki szczegółowy opis bez obawy przed karą lub represjami.
Blameless postmortem obejmuje następujące sekcje
Krok 1. Podsumowanie (wypełnij przed spotkaniem)
Ogólny zarys zgłoszenia, koncentrujący się na tym, co jest obecnie znane i jaki wpływ miało to na klienta. Pozostań przy jednym lub dwóch zdaniach.
Krok 2. Wstępna oś czasu (przed wypełnieniem przed spotkaniem)
Orientacyjna oś czasu zgłoszenia. W zależności od tego, jak szybko rozwijało się zgłoszenie, oś czasu może obejmować od kilku minut do kilku godzin do kilku dni. Jeśli Twoim głównym celem jest poprawa czasu reakcji zespołu w sytuacjach awaryjnych, powinieneś zadbać o to, aby było to mierzone do sekundy.
Podczas rejestrowania osi czasu, upewnij się, aby uwzględnić:
Kiedy zgłoszenie zostało zarejestrowane i przez kogo/jakiego procesu
Jakie działania zostały podjęte
Kiedy komunikacja była realizowana do i z zespołu
Pomysły na usunięcie skutków
Kiedy spotykasz się, aby omówić zgłoszenie, zaproś wszystkich, którzy pracowali nad zgłoszeniem. Obejmuje to zespół pomocy technicznej oraz członków zespołu obsługi klienta, którzy mogli być zaangażowani.
Przejrzyj podsumowanie, przeanalizuj harmonogram i dodaj brakujące części, a następnie przejdź do pomysłów na remediację.
Te pytania są sformułowane, aby pomóc zespołowi wziąć odpowiedzialność za problem. Istnieją pewne problemy, które wydają się być poza kontrolą zespołu (centrum danych traci zasilanie, itp.). Ale nawet w takich wydarzeniach zespół może wciąż poprawić swoją reakcję na katastrofę.
Krok 3. Wykrywanie – Jak możemy wykryć ten problem lub podobny szybciej?
Przyjmij, że ten problem lub bardzo podobny wystąpi ponownie. Jak zespół pomocy może szybciej wykryć ten problem i znaleźć go zanim zrobi to klient?
Krok 4. React – Jak możemy poprawić naszą reakcję na takie zgłoszenia?
Przyjmijmy, że zgłoszenie zostało zgłoszone. Jak szybka była reakcja? Czy stracono minuty, gdy ludzie wysyłali e-maile, próbując nakłonić kogoś do zajęcia się problemem?
Kiedy następnym razem pojawi się ten problem, jak zespół może zareagować szybciej lub w bardziej zorganizowany sposób?
Krok 5. Szybkie rozwiązanie – Jak szybciej zatamować krwawienie?
Czy gdy to się powtórzy, mamy gotowe rozwiązanie dla klienta, które pozwoli zmniejszyć wpływ problemu?
Jeśli to coś, co pogarsza się z czasem (jak atak DDOS), czy mamy szybki sposób na zamknięcie dopływu danych, podczas gdy ustalamy przyczynę źródłową?
Krok 6. Zapobieganie – Jak możemy zapobiec lub zmniejszyć wpływ problemów w przyszłości?
To często jedyne pytanie, które zespoły zadają na spotkaniach postmortem. To ważne pytanie i powinieneś spędzić tutaj dużo czasu. Jednak jeśli ograniczasz się do pytania tylko o to, jak zapobiec zgłoszeniu, unikasz wzięcia odpowiedzialności za rzeczy, które są pod twoją kontrolą (jak sposób, w jaki wykrywasz, reagujesz czy szybko naprawiasz zgłoszenie).
Podczas przeprowadzania burzy mózgów nie ograniczaj się do rozwiązań technicznych. Lepsze monitorowanie, lepsze ścieżki komunikacji, lepsze szkolenia, upewnianie się, że osoby w dziale obsługi klienta znają osoby w dziale pomocy produkcyjnej po imieniu itp.
Krok 7. Inne obszary ryzyka – Jakie inne obszary mają tę samą podatność?
Każde zgłoszenie jest wskazówką, gdzie system jest słaby. Prawdopodobnie na każde zgłoszenie, które znajdziesz, przypadają dziesiątki ukrytych w cieniu, czekających na odkrycie.
Tak jak, gdybyś zobaczył mysz w swojej kuchni. Nie masz problemu z „myszą”, tylko z „myszami”.
Istnieją prawdopodobnie inne części systemu, które dzielą te same założenia projektowe lub w niektórych przypadkach ten sam kod (nie żeby ktoś kiedykolwiek kopiował/wklejał kod).
Poświęć kilka minut na przeprowadzenie burzy mózgów nad innymi miejscami, które są podatne w podobny sposób.
Kiedy zespoły są zestresowane i przemęczone, pomijają ten krok. Uważam, że jest to najważniejsze pytanie, które należy zadać, aby wprowadzić zespół w proaktywny sposób myślenia i zmniejszyć występowanie problemów w przyszłości.
Krok 8. Kolejne Kroki (Działania)
Po zidentyfikowaniu wszystkich możliwych działań, które możesz podjąć, aby poprawić wykrywanie, reakcję, szybkie naprawy i zapobieganie zgłoszeniom… oraz po znalezieniu innych obszarów aplikacji wymagających uwagi… przejdź do podejmowania decyzji, jakie działania wybrać.
To, jak ustalisz priorytety, zależy od Ciebie. Mam jednak kilka rad.
Uzyskaj nazwę i datę dla każdego działania, które planujesz podjąć przed opuszczeniem spotkania.
Jeśli ktoś na spotkaniu jest chętny do podjęcia się jednego z działań, zachęć go do tego, nawet jeśli uważasz, że może to nie być najważniejsza kwestia do rozwiązania.
Nazwy i daty
Ogólnie stwierdziłem, że zespoły cieszą się z tego ćwiczenia (pod warunkiem, że możesz stworzyć środowisko bez obwiniania dla spotkania). Lubią analizować problem i przeprowadzać burzę mózgów nad rozwiązaniami. Jednak wszyscy czują się zajęci i przepracowani. Jeśli to spotkanie nie zakończy się przypisaniem właścicieli i terminów do rzeczy, które trzeba wykonać, istnieje duże prawdopodobieństwo, że żadne z usprawnień się nie wydarzy.
Co się stanie, to że za 3 tygodnie, kiedy ten sam problem pojawi się na produkcji (ale tym razem na większą skalę), ktoś powie: „O tak, rozmawialiśmy o naprawieniu tego.” Nie najlepsze miejsce do przebywania.
Aby temu przeciwdziałać, po prostu upewnij się, że przy każdej akcji, którą grupa chce podjąć, znajduje się imię i data.
Wyspa Refleksji Retrospektywa zespołu na koniec roku
Zastosowania:
Retrospektywy, Metodologia Agile, Spotkania
Wyspa Refleksji: Szablon retrospektywy zespołowej na koniec roku oferuje kreatywne i tematyczne podejście do retrospektyw, idealne do podsumowania roku. Oferuje elementy do refleksji nad osiągnięciami, wyzwaniami i celami, wykorzystując motyw tropikalnej wyspy. Zalety tego szablonu: zespoły mogą świętować sukcesy, uczyć się na błędach i określać zamiary na nadchodzący rok w swobodnej i przyjemnej atmosferze. Dzięki promowaniu refleksji i świętowania, Reflection Island: Retrospektywa na koniec roku wzmacnia więzi w zespołach, poprawia morale i pozwala rozpocząć nowy rok z nową energią i skupieniem.
Harmonogram wdrożenia SaaS
Zastosowania:
Agile
Szablon oś czasu implementacji SaaS oferuje wizualną roadmapę do planowania i śledzenia wdrażania rozwiązań Software as a Service (SaaS). Zapewnia uporządkowaną strukturę do definiowania kamieni milowych, przydzielania zasobów i monitorowania postępów. Ten szablon umożliwia organizacjom efektywne zarządzanie wdrożeniami SaaS, zapewniając pomyślne przyjęcie i realizację wartości biznesowej. Promując przejrzystość i odpowiedzialność, oś czasu wdrożenia SaaS umożliwia zespołom realizację projektów na czas i w ramach budżetu, zwiększając zwinność organizacji i konkurencyjność.
Retrospektywa świąteczna
Zastosowania:
Metodologia Agile, Spotkania, Retrospektywy
Świąteczny szablon retrospektywy oferuje świąteczne i celebracyjne podejście do retrospektyw, wprowadzając ducha świąt do sesji. Zapewnia elementy do refleksji nad osiągnięciami, dzielenia się wdzięcznością oraz wyznaczania celów na przyszłość. Ten szablon sprzyja poczuciu ciepła, wspólnoty i uznania wśród członków zespołu, zachęcając do refleksji nad rozwojem zawodowym i osobistym. Dzięki wprowadzeniu radości sezonu świątecznego do retrospektywy, Retrospektywa Świąteczna daje zespołom możliwość umacniania relacji, kultywowania pozytywności i skutecznego ciągłego doskonalenia.
Mapa procesu SIPOC
Zastosowania:
Zwinna metodologia
Mapa procesu SIPOC to wizualne narzędzie do dokumentowania wysokopoziomowego przepływu procesów systemu lub projektu. Pomaga zespołom zidentyfikować dostawców, zasoby, procesy, wyniki i klientów, ułatwiając holistyczne zrozumienie strumienia wartości. Ten szablon umożliwia zespołom wizualizację kluczowych elementów procesu i współzależności, pozwalając im zidentyfikować obszary wymagające poprawy i zoptymalizować wydajność przepływu pracy. Promując przejrzystość i współpracę, mapa procesu SIPOC umożliwia organizacjom skuteczniejsze dostarczanie wartości i zaspokajanie potrzeb klientów.
Szablon analizy FMEA
Zastosowania:
Agile Methodology, Strategic Planning, Software Development
Kiedy budujesz firmę lub prowadzisz zespół, ryzyko jest nieodłącznym elementem. Nie można go wyeliminować. MOŻESZ je jednak zidentyfikować i złagodzić, aby zwiększyć swoje szanse na sukces. FMEA (Failure Modes and Effects Analysis) to potężne narzędzie zaprojektowane, aby pomóc w zarządzaniu ryzykiem i potencjalnymi problemami poprzez wykrywanie ich w procesie, produkcie lub systemie. Dostrzeżesz je na wcześniejszym etapie procesu, co pozwoli Ci uniknąć kosztownych zmian, które pojawiają się późno w grze lub, co gorsza, po tym, jak wpłynęły na klientów i ich doświadczenia.
Szablon codziennego spotkania stand-up
Zastosowania:
Agile Methodology, Meetings, Software Development
Cały zespół spotyka się, aby dokonać przeglądu poprzedniego dnia i omówić nadchodzący dzień. Te codzienne spotkania, znane również jako „scrumy”, są krótkie, ale potężne - identyfikują blokady drogowe, zapewniają każdemu członkowi zespołu zabranie głosu, wspierają współpracę, utrzymują postępy na właściwym torze i ostatecznie utrzymują efektywną współpracę zespołów. Szablon ten ułatwia wersję codziennych spotkań stand-up dla zespołu sprintu. Wszystko zaczyna się od wybrania daty i godziny, stworzenia agendy i trzymania się tego samego formatu przez cały sprint.